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ABSTRACT 

We present a language-independent semantic model of the process of combining 
changes to programs. This model extends the domains used in denotational semantics 
(complete partial orders) to Boolean algebras, and represents incompatible 
modifications as well as compatible extensions. The model is used to define the 
intended semantics of change merging operations on programs and to establish some 
general properties of software merging. We determi.ne conditions under which changes 
to subprograms of a software system can be merged independently and illustrate cases 
where this is not possible. 

Keywords: software change merging, semantics, domains, software maintenance. 



1. Introduction 

Practical software systems have many different versions, all of which are con- 
stantly changing in response to changes in user needs, the operating environment, and 
the discovery of faults. Such changes often have to be developed concurrently and 
then combined, or the "same" change has to be applied to several different versions of 
the system. We call the process of combining several changes software change merg- 
ing. Tool support for this process is desirable, possibly in the form of automated 
assistant to a designer [22]. However, a production-quality tool should always produce 
either a correct result or an indication of failure together with diagnostic information. 
A clear and precise model of change merging is needed to build such tools and to 
demonstrate that they achieve the required degree of "correctness". 

This paper provides such a model and determines some of its characteristics. 
Since our goal is to formulate a language-independent definition of the requirements 
for change merging, we focus on merging changes to the meaning of a program (rather 
than changes to the concrete representation of a program). This is only part of the 
problem: a practical tool must operate on concrete representations of programs and 
produce a concrete program whose meaning agrees with our model unless it explicitly 
reports failure. Methods for change merging that operate on concrete representations 
of programs are outside the scope of this paper. A concrete method for change merg- 
ing that is based directly on a special case of the models presented here can be found 
in [2]. 
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We achieve language-independence via the constructions used in denotational 
semantics to define the meanings of programming languages. The domains used in 
traditional denotational semantics do not have enough structure to provide a general 
definition of change merging. The main contribution of this paper is a set of extended 
domain constructions that can support such a definition and a formalization of the 
notion of a semantic conflict between changes. Since exact merging is not computable 
[1], the set of inputs for which a merging tool reports a failure and the semantic merg- 
ing model produces a conflict-free result is one criterion for comparing different merg- 
ing tools. We also explore some semantic limitations on merging that are related to 
functional decomposition. 

Section 2 reviews some relevant previous work. Section 3 presents the construc- 
tion of semantic domains appropriate for program merging, first reviewing the basic 
properties of approximation lattices, then extending these lattices to Boolean algebras 
and showing the relation to Browerian algebras. The purpose of these structures is to 
extend the ordinary semantic domains to include improper values representing combi- 
nations of incompatible design decisions. This lets us model software merging as a 
total operation on these extended domains, and enables the change merging in the 
domain of program meanings to identify semantic conflicts in cases where changes 
cannot be consistently combined. Section 4 uses the algebraic structures developed in 
Section 3 to support a formal definition of an ideal operation for combining the seman- 
tics of software modifications, and determines some of the properties of this formal 
model. Section 5 presents some conclusions and directions for future work. 

2. Previous Work 

The problem of combining two versions of a functional program was formalized 
as constructing the least common extension of two partial functions in [1]. This is a 
simplified version of the problem considered in this paper, which includes incompati- 
ble modifications as well as compatible extensions. The intended semantics of merg- 
ing compatible extensions was expre.ssed using lattices and the approximation ordering 
Z used in traditional approaches to denotational semantics of programming languages 
[23,25], 

These lattice structures were refined into larger Boolean algebras to model incom- 
patible changes via a suitable difference operation in [2]. The idea behind the domain 
construction was sketched briefly, and was limited to primitive domains, cross pro- 
ducts, and a rough approximation to function spaces that was limited to additive func- 
tions (see [25] p. 105). The current paper repairs the deficiencies in the Boolean func- 
tion space construction, and introduces Boolean versions of an extended sum construc- 
tor, two of the three main power domain constructors, and recursively defined domains 
(solutions to reflexive domain equations). The current paper also formalizes the idea 
of semantic conflicts, and explores propenies of the change merging model related to 
functional composition as well as the conditions under which the result of a set of 
changes is independent of the order in which they are applied. We also show that 
change merging does not preserve monotonicity (or computability). 



We view changes as transformations from versions to versions as was done in [2], 
and prove a minimality property suggested there. Change transformations have been 
developed in a different way in [20], 

This paper characterizes the intended semantics of change merging but does not 
address concrete methods for change merging. Specific methods for change merging 
are briefly surveyed here (see [5] for more information). The first semantically based 
methods for combining two versions of a functional program were given in [1]. A 
method for merging versions of PROLOG programs is [24]. An approach to combin- 
ing both modifications and compatible extensions to while-programs based on data 
flow analysis and operations on program dependency graphs is described by Horowitz, 
Prins, and Reps [12], and this approach was subsequently improved [26]. Another 
method for solving this problem that produces fewer spurious conflict reports is 
described in [2]. A method for merging changes to prototypes with concurrent actions 
and hard real-time constraints is described in [7]. 

3. Semantic Domains for Software Merging 

This section explores semantic domains that can support change merging opera- 
tions. A difference operation is desirable for this purpose, and at least a pseudo- 
difference operation seems to be needed. Since the domains commonly used in deno- 
tational semantics do not in general provide such operations, we explore refinements to 
those domains. 

Section 3.1 reviews some relevant properties of the domains used in denotational 
semantics. Section 3.2 presents a construction that extends a class of complete partial 
orders commonly used in denotational semantics to atomic Boolean algebras (which 
provide a difference operation). Section 3.3 explores the relation of this effort to 
Browerian algebras (which provide a pseudo-difference operation). 

Every atomic Boolean algebra is a Boolean algebra as well as a lattice, and 
satisfies all of the usual laws of Boolean algebras. It is possible to understand most of 
the later parts of this paper in terms of the interpretations for the Boolean operations 
summarized in Fig. 1, without knowledge of the special properties of the atomic 
Boolean algebras constructed in Section 3.2, although some parts of the proofs depend 
on these properties. 

3.1. Lattices and Approximation Orderings 

The domains used in denotational semantics are all partially ordered sets with an 
approximation ordering " . Typical domains are special kinds of function spaces 
whose elements represent meanings of programs. An approximation f Z g means that 
5 is a compatible extension of /; g agrees with / whenever / is defined, and g may 
be defined in cases where / is not. Our model of change merging uses lattices that 
are special cases of this kind of structure. 

A lattice is a partially ordered set that contains least upper bounds and greatest 
lower bounds for all finite subsets. Lattices have a least upper bound operation u , a 
greatest lower bound operation n , a least element i , and a greatest element T . 
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All of the features of a lattice are relevant to change merging. The least upper 
bound merges all of the information contained in two elements. The greatest lower 
bound extracts the information common to both elements. The least element i 
denotes the absence of information, and is used together with r to indicate that two 
elements do not contain any common information. The greatest element 7 represents 
an inconsistency: the result of merging (all possible) incompatible information. 

Denotational semantics was originally formulated using special kinds of lattices. 
Later formulations were recast in terms of epos (complete partial orders) that are sub- 
sets of the original lattices. This was done partially to avoid overconstrained elements 
such as 7 , which do not have a natural interpretation for individual programs. In the 
context of change merging, overconstrained elements represent conflicts between 
semantically incompatible changes. Since independently developed changes can easily 
be semantically incompatible, overconstrained elements have natural interpretations in 
our context. 

Since lattice operations are applied to functions independently at each point, over- 
constrained elements may be useful for localizing semantic incompatibilities and diag- 
nosing their causes. A simple example illustrates the idea. 

[ _ , 1. 2. 3] U [4, 1. i . 5] = [4. 1. 2. 3 ^ 5] 

Here we use sequences of length four as idealized finite examples of semantic func- 
tions representing meanings of programs. Tne least upper bound merges the informa- 
tion in the two functions to produce a third, which has normal data values in the first 
three positions and an overconstrained value in the founh. The presence of the over- 
constrained value indicates a semantic conflict, its location indicates the part of the 
input space that is affected (the fourth value in the index set for the sequence), and the 
overconstrained value itself indicates the nature of the conflict (the same output has 
been simultaneously constrained to have two different and incompatible values, 3 and 
5). Thus we have a semantic model for an idealized error reporting facility. 

It is of course much easier to merge the semantics of programs than it is to 
materialize the concrete programs corresponding to the merged semantics, and the 
problem of diagnosing and locating conflicts between changes is far from being solved 
in practice. However, it does help to have a clear idea of an idealized goal for error 
reporting. A partial change merging method that can in some cases derive a program 
representation with overconstrained program elements in the parts of the program that 
produce semantic conflicts is described in [2]. Representations of such overconstrained 
program elements are detectable by syntactic operations and could be used as a basis 
for generating concrete error messages. 

3.2. Atomic Boolean Algebras 

To model incompatible changes to the semantics of a program, we need a 
difference operation to describe the information that was removed from a software 
object. If we treat the partial functions computed by our programs as sets of pairs, 
then the set difference operation captures this idea for first-order functions. Together 
with c , w, n and set complementation this struemre forms a Boolean algebra, which 
is a simple and typical example of the extended semantic domains we will be using. 
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Boolean algebras provide natural generalizations that cover higher-order functions as 
well. The motivation for our choice of algebraic structures is discussed further in Sec- 
tion 3.3. This section reviews the basic properties of Boolean algebras and shows how 
to construct the Boolean algebras for higher order function spaces. 

There are many equivalent definitions of Boolean algebras [10]. Every Boolean 
algebra is a complemented distributive lattice with respect to the partial ordering 
defined by the relations I y <=> xy = .t <=> a- + y = y . In addition to the lattice 
operations a Boolean algebra has a complement operation, which can be used to define 
a binary difference operator x - y = xy that obeys the algebraic properties of set 
difference. These structures are important for our goals of finding minimal compatible 
extensions and finding minimal change transformations. 

We use notations for operations on Boolean algebras common in circuit design. 
Unfortunately, these notations are not the same as those used for lattice operations in 
the context of denotational semantics. The correspondence is shown in Fig. 1 [2]. 

We wiU be working with a special class of Boolean algebras, those that are 
atomic. An aroin is an element that is distinct from the bottom element o and has no 
lower bounds other than itself and o. A Boolean algebra is atomic if every element is 
the least upper bound of the set of atoms it dominates (lemma 1, [10] p. 70). 

Every atomic Boolean algebra is isomorphic to the power set of its atoms, which 
becomes a Boolean algebra when u . “ . and complement are interpreted as the union, 
intersection, and complement operations on sets (theorem 5, [10]). This isomorphism 
demonstrates that the difference operator of a atomic Boolean algebra really is the 
same as set difference. It also implies that every atomic Boolean algebra is complete 
and that its structure is determined by its cardinality. A Boolean algebra (or any lat- 
tice) is complete if and only if it has least upper bounds and greatest lower bounds for 
arbitrary subsets, not just the finite ones. 
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Fig. 1 Correspondence between Lattice Notation and Boolean Notation 



The Boolean algebras used in digital circuit design are atomic and finite: elements 
can be represented as fixed-length vectors of bits, the atoms are all zero except at one 
bit position, and the cardinality of the value set is equal to a power of two. The 
Boolean algebras we use for semantic domains are mostly function spaces, and the car- 
dinality of the value set is typically infinite. 

An example of a Boolean algebra that is neither atomic nor complete is the set of 
all finite unions of half-open real intervals of the form {jt I a <x < b) where 
0 ^ a < b < I and a and b are rational numbers. The operations of the algebra are ordi- 
nary set-theoretic unions, intersections, and complements, the ordering is subset, the 
bottom element is the empty set (any interval with a = b), and the top element is the 
interval with a = 0 and b = 1. To see that this Boolean algebra does not have any 
atoms, note that there is an infinite descending chain below every element other than 
the empty set. To see that it is not complete, note that any infinite set of pairwise dis- 
joint intervals does not have a least upper bound. 

We will find that isomorphic Boolean algebras can be given quite different 
interpretations, and that some properties relevant to change merging, such as whether 
or not a given element represents a semantic confiict, can depend on the intended 
interpretation as well as on the structure of the algebra. Since the intended interpreta- 
tion of a domain is determined by how the domain was constructed, we implicitly 
label each domain with the operation that was used to construct it and consider alge- 
bras constructed in different ways to be distinct. To keep our conventions simple we 
will follow this convention uniformly and explicitly mention all isomorphisms, 
although this introduces some distinctions that are not significant. For example, the 
domains A x (3 x C) and (A x B) x C are considered to be different even though they 
are isomorphic and have essentially the same meaning. 

Our domain construction will proceed as follows. We will take some domains to 
be given a priori, and we will label them as primitive. All other domains will be con- 
structed from the primitive domains using a fixed set of domain constructors and possi- 
bly reflexive domain equations. The domain constructors are cross products, extended 
disjoint sums, and function spaces. Section 3.3 extends this by adding power domain 
constructors. 

3.2.1. Primitive Domains 

The domains representing ordinary data types will be treated as primitive. By an 
ordinary data type we mean a set whose values are either completely defined or com- 
pletely undefined. Ordinary data types can include composite data structures as long 
as it is not possible for some subcomponents to be defined while others are not. .An 
example of a data type that is not ordinary is a list type with lazy evaluation for the 
element extraction operation, since some components might be well defined while an 
attempt to extract other components might cause the program to go into an infinite 
loop. 

In denotational semantics, ordinary data types are represented as flat lattices or 
flat epos. The Boolean algebra representing an ordinary data type is the power set of 
the type with the usual set operations. 
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Each element of this Boolean algebra is a set of values of the data type that 
represents the least upper bound of those values. Proper values of the type are 
represented as singleton sets of the algebra, and these are the atoms of the Boolean 
algebra. The approximation relation C is interpreted as the subset relation, and the 
operations x + y , xy, and x - y are interpreted as union, intersection, and set difference 
operations. The completely undefined element 0 is represented as the empty set, and 
the completely overconstrained element i is represented as the set of all values of the 
data type. 

For the primitive domains, semantic conflicts are represented by sets containing 
more than one element. An element x of a primitive domain is conflict-free if and 
only X C a for some atom a. Note that the undefined element i) is conflict-free as well 
as the proper values of the type. 

The relation between the lattice construction and the Boolean algebra construction 
is illustrated in Fig. 2 [2] for a discrete type representing the states of a traffic light. 
Our construction preserves the structure of flat lattices everywhere except for the top 
element 7 . which is refined into a set of distinct improper elements in the Boolean 
algebra. The Boolean algebra can support a total and single-valued difference operator 
because the least upper bounds of distinct sets of proper data elements are all distinct. 
It is not possible to define such a difference operator for flat lattices with more than 
two elements because all of these upper bounds are identified with the single element 
T in the flat lattice. 

3,2.2. Domain Construction: Cross Products 

We use the same product space constructor used in denotational semantics, since 
the product of two atomic Boolean algebras is an atomic Boolean algebra. The atoms 
of the product space are the tuples that have an atom as one component and undefined 
elements for all of the other components. 

An element of a product space contains a semantic conflict if one of its com- 
ponents does: a tuple / e Dj is conflict-free if and only if /] and i-> are conflict-free. 




r = red, y = yellou;, g = green 




Fig. 2 A Flat Lattice and the Corresponding Boolean Algebra 
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Note that product spaces contain conflict-free elements that are not atoms and are not 
«. Since we can have a product space isomorphic to a primitive domain, we can see 
that the "conflict-free" propeny need not be preserved by isomorphism. 

3.2.3. Domain Construction: Extended Sums 

The domains produced by the classical disjoint sum construction are not in gen- 
eral Boolean algebras, nor can they be embedded in Boolean algebras. This is so 
because all Boolean algebras are distributive, but disjoint sums do not in general pro- 
duce distributive lattices. To see this let A and B be atomic Boolean algebras and con- 
sider any elements a, a' e A and h e B that are ordered as shown in Fig. 3. Such ele- 
ments exist whenever A contains at least three distinct atoms and B contains at least 
two distinct atoms. These elements fail to satisfy the distributive law: 

a + (a' b) = a + 0 X a * a' = a' 1 = (a + a' )(u + ). 

Since an embedding must preserve least upper bounds and greatest lower bounds, these 
elements will also violate the distributive law in any other lattice in which the sum 
domain can be embedded. 

We therefore reexamine disjoint sums in the context of change merging. To 
accurately represent semantic conflicts, we would like every pair of proper data values 
in our semantic domains to have a distinct least upper bound. This suggests that it is 
not really desirable to keep sum domains completely disjoint; certainly we want the 
parts of the domains containing the proper elements to be disjoint, but we would like 
to have distinct representations for all of the possible conflicts, between the maximal 
proper elements from the different components of the sum. So we suggest using cross 
products under the usual ordering (Section 3.2.2) to encode extended disjoint sums. 

This is not as unreasonable as it may at first appear: if we restrict our attention to 
the subset of the pairs that have an undefined element o in at least one component, the 
ordering on the cross product space is exactly the same as the ordering on a coalesced 




Fig. 3 Disjoint Sums Are Not Distributive 
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sum domain. The elements outside this subset all represent conflicts between elements 
from different components of the disjoint sum, and can be treated as not belonging to 
either component of the "sum". If we "encode" disjoint sums as product domains, the 
injection functions in,, the discrimination functions is^, and the projection functions 
out; that are usually used in the definitions of semantic functions involving sum 
domains can be defined as follows. 

ini(j:) = (a:, 0) injfx) = (0, x) 

iS[(p) = (pi * 0) dc (p2 = 0) isiip) = (pi = 0) dc (p2 0) 

out, (p ) = if is, (p ) then p-, el.se if p = (0. 0) then 0 el.se 1 

Thus the encoding appears to be a workable (though not very elegant) solution that 
allows domain constructions involving sum constructors to be simulated by using cross 
products, which do yield Boolean algebras. 

An element of an extended sum domain contains a conflict if either component 
has a conflict or if we do not have a o in at least one component; an element 
xe Di + Di is conflict-free if and only if xi and x-> are conflict-free and either x, = o or 

xi - 0 . 



3.2.4. Domain Construction: Function Spaces 

The continuous function space constructor of denotational semantics does not 
preserve Boolean algebras, but the function space construction used in ordinary 
mathematics does. If A and B are atomic Boolean algebras, then the complete func- 
tion space A S is the atomic Boolean algebra whose elements are all of the func- 
tions from A to B with the natural pointwise ordering. The ordering, distinguished ele- 
ments, and operations of the function space are described by the following relation- 
ships. 

(a) / C g <=> \fx eA[f(x)C i'(x)l 

(b) 0(x) = 0 

(c) l(x) = 1 

(d) (/ + g)(x) = f(x)+ gix) 

(e) (/ s)(x) = _f^) gix) 

(f) if )ix) = fix) 

(g) (/ - g)(x) = fix) - gix) 

The relation (a) is the standard ordering for function spaces in denotational semantics, 
and implies relations (b) - (g). The relations (b) and (c) describe the connection 
between the top and bottom elements of the function space A B and the top and bot- 
tom elements of its range algebra B. The relations (d) - (g) are homomorphic exten- 
sion rules which define the operations of the function space in tenns of the operations 
of its range algebra. The operations are well defined because B is complete, so that 
least upper bounds exist for all subsets of its atoms. The Boolean algebra properties 
are satisfied for the function space because they are satisfied by the values of the func- 
tions at each point in A . 

The resulting function space is an atomic Boolean algebra. The atoms of A B 
are functions y] that are undefined at all points of the input space A except for the 
point x , and have the value y at that point, where x can be any point in A and y can 
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be any atom of B . 

5[-t. )'](;) = if X = z then y else ». 

Every element of the function space is the least upper bound of the atoms it dominates 
because the corresponding property is true in B for the values of those functions at 
every point in A , since B is an atomic Boolean algebra. 

The classical function space construction used in denotational semantics produces 
subsets of our function spaces. Note that we cannot limit the construction to just the 
monotonic functions (or just the continuous functions)/ because a Boolean algebra 
must be closed under complements, and the complement of a monotonic function is 
anti-monotonic. 

Since our function spaces are complete, they satisfy the weaker completeness pro- 
perties needed to show the existence of least fixed points of continuous functions. 
They also contain all of the continuous functions, and hence support recursive 
definitions for elements of the function spaces. 

A function contains a conflict if its value at some meaningful point contains a 
conflict: a function /: D, D; is conflict-free if and only if / (x) is conflict-free for all 
conflict-free xeD^. We restrict our attention to the conflict-free points in D\ because 
computable (monotonic) functions can be expected to produce conflicts at overdefined 
points. 

3.2.5. Domain Construction: Refle.xive Domains 

Reflexive domains are the solutions to recursive domain equations, in which 
equality is interpreted as lattice isomorphism. Since our function spaces contain all 
functions, our function space constructor strictly increases the cardinality of the space, 
so we cannot hope to find spaces that are isomorphic to their own function spaces. 
This is one of the classical problems in denotational semantics, and it implies that the 
function space construction of Section 3.2.4 cannot be used in recursive domain equa- 
tions. However, if we are willing to restrict ourselves to distributive lattices and 
embed solutions to domain equations in larger Boolean algebras, there is a way out via 
the space of continuous functions used in denotational semantics. 

We start with a lemma that relates properties of domain constructors to the pro- 
perties of reflexive domains defined using those constructors. 

Lemma 1. If F is a continuous domain constructor [23] that preserves distributiveness 
then the minimal solution to the domain equation D =F(D) exists and is distributive. 
Indeed, any property that is preserved by the domain constructors and can be 
expressed as an equation or inclusion between expressions denoting elements of a 
domain is satisfied in D. 

Proof: D exists by (theorem 4.2.8, [23]). The minimal domain i contains only one 
point, so all inclusions and equations on elements are trivially satisfied, and in particu- 
lar we have x j(y H:) = (x Ly)r.(.t Uc) and x n (y U c) = (x “y) U (x n c) for ail 
X. y, : 6 * . So the domain i is distributive. Since F preserves distributiveness, the 
approximating domains F"(i ) are distributive for all natural numbers n, by induction. 
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By (lemma 4.2.5, [23]), x Zy <=> Vn ( ti„’U) Z rt,’(y)], where k’ are the projection func- 
tions from D into F"(i ) defined in [23]. (Two elements of the limiting domain are 
ordered if and only if their projections into all of the approximation domains are 
ordered in the same way). This implies xuy =: in D <=> Vn[rt„’(x) u rt„'(y) = ;r„’(c)] 
and similarly for n . Since x = y <=> x Z y & y Z x we also have x = y in D <=> 
V /1 [n„*(x) = rt„*(y)]. By structural induction it follows that any equation among finite 
expressions built using variables, L . and n is satisfied in the limit domain D if and 
only if the expression with each variable v replaced by the corresponding projection 
k’(v) it is satisfied in all the approximating domains F( l ). So D must be distributive, 
since all of the approximating domains are distributive. 

Now we can proceed to the main theorem. 

Theorem 1. The solution to any domain equation composed of given Boolean alge- 
bras and domain constructors that preserve distributiveness can be embedded in a 
Boolean algebra. 

Proof: Boolean algebras are distributive lattices by definition. Lemma 1 says that the 
solution to a domain equation composed of domain constructors that preserve distribu- 
tiveness is also a distributive lattice. Every distributive lattice can be extended to a 
Boolean algebra ([16], p. 450 ff.). So the result follows. 

The primitive domains of Section 3.2.1 are all Boolean algebras. Cross products 
and function spaces of distribudve lattices are distributive (theorem 13, [17], Ch. 14). 
The lattice of continuous functions is distributive because it is a sublattice of the full 
function space. Extended disjoint sums are encoded as cross products in Section 3.2.3. 
So the solution to any domain equation expressed using these constructs will be a dis- 
tribudve lattice, which can be embedded in a Boolean algebra. This Boolean algebra 
is a good candidate for hosting change merging operadons because it is a natural com- 
pletion of the semantic domain that contains distinct representations for ail possible 
conflict elements. 

The solution to a reflexive domain equation is labeled with the outermost domain 
constructor on its right hand side, and the appropriate definition of conflict-free ele- 
ments is determined accordingly. 

These construcdons allow us to formulate change merging operations for most of 
the programming languages covered by classical denotational .semantics. This does not 
include the class of languages with parallel or nondeterministic operadons, which are 
considered briefly in the next secdon. 

3.3. Browerian Algebras 

Boolean algebras are sufficient for modeling the semantics of change merging for 
the programming languages whose semandcs can be expressed using the construcdons 
of Secdon 3.2. Some work on concrete methods for change merging has been based 
on a more general class of Browerian algebras [21]. This section discusses the role of 
Browerian algebras in modeling the semantics of change merging. 
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A Browerian algebra is a lattice with a pseudo-difference operation - that 
satisfies the property - y I : <=> .t Z y + c. Every Boolean algebra becomes a 
Browerian algebra when it is equipped with a difference operator as defined in Section 
3.2, but there exist Browerian algebras that are not Boolean algebras. In particular, 
Browerian algebras need not satisfy the law x=x. The difference operator of a 
Boolean algebra must satisfy both of the following properties. 

PI. (x -y) + (xy)=x 

P2. (x - y)y = 0 

The pseudo-difference operator of a Browerian algebras must satisfy PI, which says 
that all of the information in x is either contained in y or is contained in the part of x 
that is not in y; (x - y) + (ay) = ((x - y) + x)((x - y) + y) = xU + y) = x if we note that 
X - yZx and use (proposition A.12, [21]). However, the pseudo-difference operator 
may fail to satisfy P2, which says that the result of removing y from x does not con- 
tain any of the information in y. It is easy to see that this disjointness property holds 
in a Boolean algebra: (x-y)y =xyv =x0 = ». The pseudo-difference operator is thus 
not really a difference operator, because it may not remove all of the information con- 
tained in y, although it must remove as much as possible without violating property 
PI. This means that the underlying lattice of a Browerian algebra need not have 
sufficiently fine resolution to separate x and y, in the sense that it may not be possible 
to remove all of the information in y from x without also removing some information 
in X that is not contained in y . 

We have worked with Boolean algebras because they provide a natural represen- 
tation for precisely identifying the sources of semantic conflicts, proofs are simpler, 
and the extra generality of Browerian algebras is not needed to express the semantics 
of change merging for most programming languages. Separating the elements of the 
semantic domains in the sense of the previous paragraph is usually not an issue 
because the data values of most programming languages are disjoint (can be modeled 
as a flat cpo) or can be assembled from disjoint parts (using cross products or func- 
tions). 

Browerian algebras were used in [21] because the concrete dependence graph 
representations of programs do not have a Boolean algebra structure. However, we 
note that the semantic correcmess of the HPR algorithm [12] as well as of the variant 
in [21] is not derived from the Browerian algebra structure of the dependence graph 
representations of the programs, but rather from the concrete properties of program 
slices. 

A realistic example of a semantic domain that should properly be modeled as a 
Browerian algebra is the domain of maximum execution times (METs) for a language 
with hard real-time constraints such as PSDL [8]. Since a larger number represents a 
weaker timing constraint, the approximation ordering Z for this domain is the total 
ordering > on numerical values. This is an extreme example of lack of separability 
because two constraints cannot be disjoint unless one of them is the vacuous constraint 
oo (the bottom element of the lattice). The lattice of MET values is a Browerian alge- 
bra with X - y = if X Q y then « else x. Since every Browerian algebra is a distributive 
lattice (theorem 1.3, [19]), every Browerian algebra, including the MET domain, can 
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be extended to a Boolean algebra by ([16], p. 450 ff.). A fragment of the MET 
domain and its embedding in a Boolean algebra are shown in Fig. 4, where proper ele- 
ments have bold lines and the artificial elements added by the embedding have thin 
lines. Unlike the extended data domains of Section 3.2, where the artificial elements 
represent conflicts between distinct proper elements, the extra elements in this exten- 
sion to a Boolean algebra provide artificial differences between proper elements that do 
not have realistic interpretations. Change merging in this Boolean algebra can result in 
an improper element, while change merging in the Browerian algebra yields a proper 
element that dominates the result in the Boolean algebra. For example, merging the 
change from 2 to 1 with the change from 2 to 3 according to the model explained in 
Section 4 yields the improper element (1 - 2) + (1)(3) + (3 - 2) = 3 + (1 - 2) in the 
extended Boolean algebra and the dominating proper element (1 - 2) (1)(3) + (3 - 2) = 1 

in the Browerian algebra, where + and - denote the operations from these algebras 
instead of the usual operations from arithmetic. This suggests Browerian algebras may 
provide appropriate change merging models for data domains with overlapping proper 
elements that cannot be separated into disjoint proper components. 

A standard construction for Browerian algebras involves topological closure 
operations [18]. A topological closure operation on a Boolean algebra of sets is a 
function from sets to sets that satisfies the following properties for all sets .t and y in 
the domain of the Boolean algebra; 

(Cl) X e C(x), 

(C2) C(C(x)) = Cix), 

(C3) C(x<uy) = C(x)<uC(y) and 
(C4) C({}) = {} 

Note that many "closure" operations commonly used in computer science are not topo- 
logical closure operations. For example, the transitive closure of a graph does not 
satisfy condition C3. A set x is closed relative to C if Cix) = x. The closed elements 




Fig. 4 Extending the MET Browerian Algebra to a Boolean Algebra 
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of any Boolean algebra of sets with a topological closure operation C forms a 
Browerian algebra under the operation x - y = C(x -y) (theorem 1.14, [19]) and every 
Browerian algebra is isomorphic to an algebra constructed in this way (theorem 1.15, 
[19]). The connection to topology is that every topological space is a Browerian alge- 
bra and every Browerian algebra is isomorphic to a subalgebra of the algebra of closed 
sets of a topological space (theorem 1.19, [19]). 

In particular, the set of all downwards dosed subsets of any lattice forms a 
Browerian algebra under the construction outlined above. The downwards closure is 
defined by DC(s) - [y i 3x e s.y C x ], and can easily be seen to satisfy the properties of 
a topological closure operation. Similar results hold for the upwards closure 
UCis) = {yl 3x € sjc I y }. These properties turn out to be relevant to power domains. 

3.3.1. Domain Construction: Power Domains 

We saw in Section 3.2 how the semantic domains for many classical program- 
ming languages can be naturally embedded in Boolean algebras. The constructions of 
Section 3.2 do not cover languages with parallelism and nondeterministic constructs, 
whose semantic domains usually include power sets (power domains). Several 
varieties of power domain constructions have been proposed for defining the semantics 
of programming languages with parallelism. The approximation orderings on these 
domains are only quasi-orderings, and the relation x s y <=> xZy<S;yCx is an 
equivalence relation that is weaker than equality. The approximation relation becomes 
a partial ordering on equivalence classes in the quotient lattices with respect to this 
equivalence relation, but it is less cumbersome to represent each equivalence class by 
its largest member (the set with the most elements). There are three main variations 
on the power domain construction; the Hoare power domain, the Smyth power domain, 
and the Egli-Milner power domain. It turns out that the equivalence classes for the 
Hoare power domain are represented by the downwards closed subsets of the underly- 
ing lattice, those for the Smyth power domain are represented by the upwards closed 
subsets, and those for the Egli-Milner power domain are represented by the convex 
closed subsets [23]. 

Since the downwards closure and the upwards closure satisfy the topological clo- 
sure properties C1-C4 above, the Hoare and Smyth power domains have a natural 
Browerian algebra structure, which implies that they are distributive lattices and can be 
extended to Boolean algebras. This implies that our model of the semantics of change 
merging can be applied to both the Hoare and Smyth power domains, and that theorem 
1 can be applied to reflexive domain equations containing these power domain con- 
structors. We leave open the question of whether the Browerian or the Boolean model 
of change merging is more appropriate for these domains. 

An element of a power domain represents a set of possible outcomes. Such an 
element has a semantic conflict if any of the possible outcomes have a conflict; a set 
s e P{D) is conflict-free if and only if x is conflict-free for all x € j. 

We note that the convex closure CC{s) = [y i 3x, c € s.x I y C r ) does not satisfy 
the topological closure property C3 above, so it is not a topological closure operation 
and does not support the Browerian algebra construction. In fact, the Egli-Milner 
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power domain is not in general a distributive lattice, as demonstrated by the following 
counterexample. Fig. 5. shows a four element Boolean algebra (a) and the Egli-Milner 
power domain derived from it (b). This power domain is not a distributive lattice 
because (a.h} ({a.ft. 1} ~ {a}) = {ci.h} u {0. a} = [ci. hj ^ (a. b. 1} = 

{(i. b. 1} n {a. 1} = u 1}) n ({a.b} Li ({a }) where the least upper 

bounds and greatest lower bounds are taken with respect to the Egli-Milner ordering 
[23] shown in Fig. 5. (b). Since every Browerian algebra is a distributive lattice, 
Egli-Milner power domains cannot be extended to Browerian (or Boolean) algebras. 

We conclude that none of the known models of change merging apply to 
languages whose semantics involve Egli-Milner power domains, since all of these 
models depend on (at least) a Browerian algebra structure. This issue is relevant to 
applications where programs that can fail to terminate must interact in a nondeter- 
ministic way (typically via parallel processing). The formulation of an appropriate 
model of change merging for this class of languages is left as an open problem. 

4. Language-Independent Model of Software Merging 

This section discusses some properties of the change merging operator in [2], 
which is defined as follows. 



A 



a 







(a) Boolean Algebra 

Fig. 5 The Egli-Milner Power Domain is not Distributive 
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f[g]h = (f- g) + f h + (. h- g) 



(Ml) 



We know that if - g)+ f h-r(h - g) = if - g)+fgh + {h - g) because 
f h = f hi g + ~g)=fgli+ f~g li and f~g hZ~g h = i h - g) (this equivalence holds 
also for Browerian algebras, but the proof is longer). Thus our definition of /[ g] h 
coincides with the negmajoriiy operation f[g]h defined in [11] and the integration 
operation f[g] It defined in [21]. The name "negmajority" was motivated by a propo- 
sitional calculus interpretation of a Boolean operator that is true if and only if a major- 
ity of the three values is true after the middle value is negated. Our operator defines 
the same Boolean function, but it is interpreted in a much larger Boolean algebra 
representing the space of meaning functions for programs, rather than in the two- 
valued Boolean algebra of propositional calculus. Reps’ version of f[g]h is defined 
in terms of the pseudo-difference operation of a Browerian algebra, instead of the 
difference operation of a Boolean algebra, because the graphs used to represent pro- 
grams in his algorithm do not satisfy all the properties of a Boolean algebra. How- 
ever, we have seen in Section 3 that the semantic domains for sequential programs can 
be extended to Boolean algebras, 

4.1. The Relation to Minimal Change Transformations 

Informally, an operation for combining changes to functions should be able to 
apply the change defined by the difference between two versions g and / of a func- 
tion to some other version h. In [2] we showed how to infer a mapping from versions 
to versions from the effect of a change on a particular base version g. This was done 
by characterizing the change from a function g to a function / in terms of the com- 
mon part / g, the part that was added / - g, and the part that was removed g - / , as 
illustrated in Fig. 6. [2], These components were shown to be disjoint and to contain 
all of the information in the functions / and g, so that any change to a function can 
be characterized by the part that was added and the part that was removed. 

We formalize the idea of a transformadon f[g] that changes a base version g 
into a modified version / as follows. We propose that change transformations should 
be functions of the form T[«. /;] where T[«, b]ix) = (a - a) -r h for all x, and seek the 
smallest transformadon such that T[a, !>](«) = / (relative to the ordering denned by 




Fig. 6 Characterizing Software Changes 
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T[ai, /;iJ Z T[u 2 , Z;;] <=> ^ This is based on the following assump- 

tions: 

(1) The information added as well as the information removed by a given change 

transformation should not depend on what version the change transformation is 

applied to, and 

(2) The only additions and removals included in the change transformation should be 

those necessary to transform g into /. 

As was suggested in [2], these assumptions uniquely determine / [ »]: 
/[ gJ = T[ g - - g]- To see that this change transformation maps g into / note 

that T[g - - g](g) = (g - ( g -/)) + (/- g) = g g7 + fl = gl+ gT + lf = 

o-r(g-^'g)/ = f. To see that it is the smallest such transformation, suppose that 
{g-a) + b = f. Then f - g = f~g= ( ga + b)~g = g~gci + b~g = b~gCb and 
g - f = gT = g( g^ -r b) = g(J> + a)h = ab ~ a . So T[ g - - g] ~ T[a. b]. 

This minimality property suggests that change merging should be defined by 
/[ g] /i = ( b - ( g - /)) + (/ - g). This was shown to be equivalent to (Ml) in [2]. 

We now assess the adequacy of our formalization of the change merging process. 
By identifying programs with the functions they compute, we have ignored non- 
functional attributes such as computational efficiency and program understandability. 
The result of a change merging operation must certainly compute the correct function, 
and it may be subject to other constraints. These other constraints are beyond the 
scope of the current paper. Change merging that involves efficiency-improving 
modifications is addressed in [2], which suggests a method for program change merg- 
ing that can accommodate efficiency improving changes as well as changes in program 
behavior. This method prefers program realizations from the changed versions over 
those in the base program in cases where several different realizations of the same 
semantic (sub-)function are present. The difficulty of recognizing efficiency-improving 
changes increases sharply with the size of the change and is undecidable in general. 
Automated capabilities in this area are necessarily limited, and can be augmented with 
declarations of programmer intent in the form of optional specifications for program 
fragments. 

A related concern is the treatment of programs that do not terminate. Our formal- 
ization of change merging is intended to apply to any programming language that can 
be modeled by meaning functions over a fairly wide class of semantic domains, as 
described in Section 3.2. The effect of the change merging function defined in this 
section depends on the semantic model of the programming language being discussed. 
These models can differ considerably. In a simple imperative language whose pro- 
grams denote functions from states to states, a program that immediately enters an 
infinite loop is equivalent to one that causes some state changes and then enters an 
infinite loop, because in both cases there is no final state, and hence there are no 
observable results. Thus a change from the first program to the second would have no 
effect on program behavior, since we would have g - / =o = / - g. For languages 
with I/O facilities, programs can denote functions from pairs (containing an input 
sequence and a state) to pairs (containing an output sequence and a state). In such a 
model, a program that enters an infinite loop immediately computes a different 
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function than a program that first produces some output and then enters an infinite 
loop. A change from one to the other would have definite effect on program behavior 
in such a case, A different approach to specifying the semantics of programs that are 
not intended to terminate can be found in [3]. 

4.2. Change Merging does not Preserve Monotonicity 

In Section 3 we motivated the need for function spaces containing functions that 
are not monotonic via a rather indirect argument. Now we are in a position to show 
that change merging can produce non-monotonic functions from monotonic ones. The 
following example shows three simple monotonic functions that produce a non- 
monotonic function via change merging. 

X fix) six) hix) (/l5]^)(x) 

1 2 1 L L 

1 2 _ 1 2 

Since every computable function is monotonic, this shows that the result of merging 
changes from compuuble functions to computable functions need not be computable. 
Thus the presence of conflicts is not the only factor that can lead to a situation where 
there does not exist any program that realizes the merge defined by a base program 
and two modified programs. This also shows that the domains of traditional denota- 
tional semantics must be extended to treat change merging as a total operation. 

4.3. Commutativity and Order Dependence 

Some of the known properties [11,21] of the change merging operation are 
shown below. 

1. h[a]c = c[a]h 

2. ih[a]c)[a]d = h[ct]ic[a]d) 

If we treat [«] as a binary operation, the first property says [a] is commutative, 
and the second says that p/] is associative. These properties imply that the order in 
which a set of changes to the same base version is combined does not matter. 

We can also see that in general two change transformations commute whenever 
neither one removes information that the other adds. We can view the change merging 
operation as the application of a function T[a.b] to a program. Since 
(/ - g)is - f) = ^ we know that every change merging operation corresponds to a 
change transformation T[«. h] for which ah = «. This says that in a minimal change 
transformation, none of the information that is removed is added back. We have 

T[ai, fciKTpti, /?i](x)) = ({(x - at) + />i) -«:) + /?:= X a 2 + h^ U2 + />:, 

T[ai, /7i](T[ai, i>J(x)) = (((x - a^) a |) + /?!= X ai cii + /?,. 

Clearly these are the same if ^77 = />, and bi^ = />:• These conditions are 
equivalent to /?i C aT and a7. which are equivalent to /;ia; = 0 and 63 a 1 = 0. So 
these conditions are sufficient for the transformations to commute. To see they are 
necessary, assume the transformations commute, and substitute a, forx: 
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ai fli Ui + bi U2 +h2 = (i\(i2 U\ +bz<^\ ^i. 

(i + bia2 +b2 = (i + bzai +bi, 
b \ (1 2 + b2 — b2 Cl \ + b i. 

If we multiply both sides by «i we get 

0 + a [/72 = 0 + 0 , 
a 1^2 = 

Similarly, ^ 2^1 = Thus we have shown that /[^](/[u]j:) = r[u](/[g]j:) if and only if 
( / - g)(u - / ) = 0 and (/ - u X 5 - / ) = 0 . 

This result tells us what we must check to see whether a set of changes will give 
us the same result independently of the order in which the changes are merged. In 
case some changes override each other, in the sense that one removes information that 
another adds, then applying the same changes in a different order can intuitively be 
expected to give different results: the last transformation to be applied gets the final 
say about what should be done about the disputed information (to add or to remove). 
In such cases, human guidance is needed to resolve the relative priority between the 
two changes, possibly by going back to the requirements and the underlying 
justifications, and determining which change is more important. 

4,4, Properties Related to Functional Composition 

Independent modules are a basic requirement for programming on a large scale. 
We would like to have localized methods for analyzing and processing programs, so 
that the analysis can be decomposed into smaller independent subproblems. Such 
decoupling makes human understanding of large systems possible, as well as con- 
current team efforts. It also leads to computational efficiency and opportunities for 
parallel computation in automated processing of programs. Thus to shed some light on 
the feasibility of change merging for large systems, we consider the interaction 
between program merging and functional composition, which we denote by / , ^ 
where (/ , g)(x) = /( g(x)). The urge to divide and conquer leads us to investigate the 
following distributive property. 

(?) (/: o /i)(( o gi)]( Ih o Ih) = if z[ gz] bz) o if {[ gi] bi) 

This expression describes two changes to an implementation that consists of two 
modules, where the output of the front end module gi is connected with the input of 
the back end module gz- The left hand side represents the result of merging two 
changes to the system in one big operation, while the right hand side merges the 
changes to the front end and the changes to the back end in two independent opera- 
tions and then connects the merged versions together. Although this distributive pro- 
perty appears to be plausible, it turns out to be false, as illustrated by the following 
example over the data values {1, 2, 3, 4}. 
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Example 1. 



X 

1 

2 

3 

4 



/: S: 1^2 

1111 

3 2 2 3 

4 4 4 4 

2 3 3 2 



/i *1 /i[5il*i /:U2l o /il ^il *1 

1111 1 

3 3 2 2 3 

4 4 4 4 2 

2 2 3 3 4 



^ /: o /i if: o /i2 0 *1 

11 1 1 

2 4 4 2 

3 2 3 3 

4 3 2 4 



(/: 0 /i)[ o SiK f>2 o h{) 
1 
2 
3 

3'J4 



This example shows that the desired distributive property can be false even for well 
behaved functions and changes that do not conflict (compare the results for jc = 2 or 
X = 3). This negative result is somewhat surprising, because it implies that changes to 
sub-functions can interfere even for purely functional programs. The interference 
effect demonstrated above is thus completely unrelated to classical concerns about cou- 
pling between modules due to side effects or state changes. 

Although the interference effect comes from different coincidences of equal 
values in different versions of the functions, it is not caused by several different values 
being mapped to the same value by the individual functions: note that all of individual 
functions in Example 1 as weU as their compositions and the results of the merges are 
one-to-one. Thus the problem lies in the relationships between the versions, and is 
unlikely to be preventable via localized restrictions that can be applied to each of the 
versions independently. 

The circumstances where this interference effect shows up are complex and not 
very intuitive. For example, one case where the interference effect shows up without 
producing any local or global conflicts is when there is some input value x for the 
front end for which the first change does not affect either the output of the front end 
or the output of the entire system (/:(/iU))= .g:(gi(x))), and the 
second change transforms the output of the front end into a value affected by the first 
change to the back end but not affected by the second change to the back end 

ifzihiix))* g2(lti(x))= h.Uiiix))). 



A concrete example of this is a simple text formatter composed of two parts. The 
front end determines which words go on each line, and the base version puts as many 
words as will fit. The back end adds extra space between the words, and the base ver- 
sion adds enough space to make the right margin even on every line except the last 
line of a paragraph. The first change affects only the back end, which is changed to 
adjust the right margin of the last line of a paragraph in those cases where the space 
left at the end of the line is strictly less than a given tolerance T, where T > 1. The 
second change affects only the front end. which is changed so that if the space left on 
a line when no more words from the following text will fit is greater than the space 
left on the previous line plus the length of the last word on the previous line, then the 
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last word of the previous line is moved up to the current line. The interference effect 
will show up for an input where the space left on the last line of the paragraph is 
exactly equal to the tolerance T, the previous line is completely full, and the last word 
on the previous line is one character long. If we merge the two changes in a single 
global operation then the merged version will move up the last word of the previous 
line and will not adjust the right margin of the last line. If we merge the two changes 
in isolation and combine the results, then the resulting program will adjust the right 
margin of the last line in addition to moving up the last word of the previous line. 
The two results are clearly different. 

Also note that it is possible for the true merge of the compositions to contain a 
conflict even if the independent merges of the changes to corresponding subfunciions 
are conflict-free (compare the results of example 1 for x = 4). Approximate change 
merging methods must be safe to be practically useful: they must never silently turn a 
real conflict into a proper (but incorrect) result, although they may occasionally report 
potential conflicts that are not really there. This implies that unrestricted changes to 
different subprograms cannot in practice be merged independently, and that interpro- 
cedural analysis is necessary for reliable change merging. Thus correct divide and 
conquer methods for unrestricted change merging cannot exist, at least relative to 
modularizations based on functional decomposition. 

This is quite unwelcome news for those concerned with the evolution of large 
software systems, because functional decomposition is the modularization principle 
underlying many widely used approaches to systems analysis and software design, 
such as structured analysis. We discuss the implications of this for the practitioner at 
the end of this section, after examining in more detail the conditions under which 
change merging can and cannot be performed independently for the components of 
functional decompositions. 

Some weaker distributive properties related to change merging do hold. The fol- 
lowing calculation shows that functional composition distributes over the program 
merge operation from the right 

Property P3 

(/[.-I =(/!+/ 

= (/ o c)(7 o c) + (/ o c)( /l o c) + (~^ o C)( h o c) 

= (/ o c)( ^ o c]( /l oC) 

The derivation uses the fact that 7 « c = T7T . This property says that the result of 
merging two changes is the same, independently of whether the inputs to the module 
that has been changed are supplied directly or come from another module. This is 
what most programmers would expect. We note that composition on the right may 
mask some conflicts in / [ ^1 /i, because the range of c may be a strict subset of the 
domains of /, and h that may not include some potential conflicts between those 
functions. 

Functional composition does not always distribute over program merging from the 
left, but half of a distributive law is possible for conflict-free monotonic functions on 
primitive domains restricted to conflict-free portions of the input space. The restriction 
to monotonic functions is reasonable because every computable function is monotonic. 
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The restriction to conflict-free functions is also reasonable because conflicts can be 
introduced only by a process of combining changes that operates in an extended syn- 
tactic domain; for every programming language we have seen, every program that fol- 
lows the syntax rules of the programming language is conflict-free. The restriction to 
conflict-free inputs is reasonable because there is no way to create self-contradictory 
input values on real computer systems. The restriction to primitive domains is less 
desirable, but it is necessary, as we demonstrate below. We start with a definition 
summarizing characterizations of semantic conflicts from Section 3 and a lemma. 

Definition. An element x of a primitive domain (Section 3.2.1) is conflict-free if and 
only if a C u for some atom a. A tuple x € Dj x £>2 is conflict-free if and only if and 
Xi are conflict-free. An element x s D, * D 2 of an extended sum domain (encoded as a 
cross product) is conflict-free if and only if xi and x: are conflict-free and either xi = 0 
or X; =0. A function /; D, D 2 is conflict-free if and only if /(x) is conflict-free for 
all conflict-free x€l>i. A set x s P(D) is conflict-free if and only if x is conflict-free 
for all X B s, where PiD) can denote either the Hoare power domain construction or the 
Smyth power domain construction (Section 3.3.1). 

Lemma 2. If /. s-.D^^D-, are restricted to the conflict-free portion of Di, 
is monotonic. / is conflict-free and D- is a primitive domain ±en 
(c o /)(c o g) Z (c- , /)(c , 1). 

Proof: 

Since / is conflict-free, fix) is conflict-free for all conflict-free x e Di. 

Let X s £>i. Then / (x) 2 a for some atom a. since D; is a primitive domain. 

Case 1: u I ,!>(x). Then f(x)Z !;(x). 

So c(f(x))Z c( i’(x)) and c( f {x))c( i>(x)) = 0“ c(f(x))c{~S(x)). 

Case 2: a »U) = «. Then fix) flx) = 0 since fix) six) Z a six)- 
Then fix) Z ~'(x). f(/(x)) I c(~»(x)). and ci fix)) = cifix))ci~sU)), 
so ci fix))ci iHx)) Z cifix)) = cifix))ci~six)). 

Since a is an atom, cases 1 and 2 cover all possibilities. 

So ic o f)ic o g) 2 (c o f)ic o ~s) since c(/(x))c( ^(x)) Z df ix))ci~six)) for all x. 

Theorem 2. If /, s- hiDi-^D^ are restricted to the conflict-free portion of D,, 
c: I>2 £>3 is monotonic, / and h are conflict-free, and D -^ is a primitive domain then 

ic o f)[c o s](c oh)Cc oif[s] h) 



Proof: 



ic o f)[c o sKc o h) 

= ic o f)ic o s) + (c o f)ic o h) + (cTTKc o h) 
2 ic o f)ic o~S)^ic o f )ic o A) + (c o Die 9 h) 
Z C o ifD -r c oif ll)-^ c o il h) 
c c oifl + / A + 1 A) 

= C oifls] h) 
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The following example shows that the inequality in theorem 2 is sometimes strict. 



Example 2. 

f g h c(l) c(2) c(3) 

1 2 3 4 4 5 

c(f)[c(g)]c(h) = 4[4]5 = 5 

c(f[g]h) = c(l[2]3) =c(lu3) =c(l)uc(3) = 4u5 ^ 5 

Together with property P3, theorem 2 says that if two changes affect only one module 
of a system and we merge the two changes to the module in isolation, then the result 
of replacing the original module with the doubly-changed one in the system is con- 
sistent with the (ideal) result of merging the corresponding versions of the entire sys- 
tem. The fact that theorem 2 is an inclusion rather than an equality means that some 
conflicts that appear when merging the changes to the module in isolation might not 
really be conflicts if the change merging operation were expanded to act on the context 
c (the system in which the module is embedded) in addition to the base version ^ and 
the two modified versions / and li of the impacted module. This seems natural 
enough, since the context c is free to map two incompatible intermediate values f(x) 
and h(x) into the same value. 

Theorem 2 behaves like a partial correctness result even though the inclusion 
appears to go in the wrong direction, because it is not possible in practice (under the 
hypotheses of the theorem) for the left hand side to be undefined and the right hand 
side to be a proper value unless the isolated merge /[ifl/t produces a conflict. We 
can see this as follows. A strict inequality in theorem 2 is possible at a given point in 
D 1 only if the values of / , and h are all distinct, because c ( / ( ^] ^) = c(f) = 
c(f)[c(g)]c(g) and c(/(«]/)= c(/) = c(/)(c( j>)]c(/). If c is computable we must 
have c(_)= _ except when c is a constant function, and in that case theorem 2 
becomes an equality. This gives us c( _ ( i*] h) = c(h) = i [c( ^)]c( h) = 
c( _ )[c( »)]c( /i). Thus strict inequality is possible only when the values of /, g, and 
h are all distinct and f ^ L * h, and in that case the value of f[g] h at the given 
point represents a semantic conflict, since is a primitive domain. 

Most programmers would expect these properties to be true in general. However, 
this is not the case: we have proved theorem 2 only when the intermediate domain 
is primitive, and it turns out that the theorem does not hold if we remove that restric- 
don. To see that theorem 2 need not hold if we relax the requirement that is a 
primidve data domain, consider the following example, in which and are primi- 
dve domains containing numbers and Di contains 6 -tuples of numbers. 

Example 3. 

Ti = /(2) = (2, 2. i. i, i,2] c(T.) = 2 

T 2 = g{2) = (2. i , Z i . 2. i ] c(Tj) = 2 

Tj = KD = [ i , 2. Z 2. i , i ] ciTj) = 2 

T 4 = /(2)t ^(2)1 /i(2) = [Z Z Z 1 . 1 . 1 ] cdj = 3 ^ 2 = cdOlcd.Jlcdj) 

In this example the tuples Tj - T 4 are all incomparable, so that monotonicity does not 
impose any reladonships between their images under the function c. The fact that 
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theorem 2 need not hold for all conflict-free monotonic functions may be even more 
surprising than Example 1, because it shows that there can be interference between 
functional composition and a single program change that produces a conflict-free result 
when carried out in isolation. This can happen if the intermediate domain Dt contains 
partial functions or partial data structures (which are realized via lazy evaluation in 
some functional programming languages). Although the computations in Example 3 
are somewhat unusual, the function c can be realized (via several applications of a 
non-deterministic operation that evaluates two expressions in parallel and returns the 
value of the first one that terminates). 

Some positive results are also possible for the simpler subproblem of combining 
compatible extensions to a program [1]. The simplification that occurs when merging 
compatible extensions is described by lemma 3. 

Lemma 3. If ^ / and g Z h then f{s]h= f -r h. 

Proof: 

/[ !?] h = /I ! Ii 

= fl + f g f S It -^1 It 

= f h since g = f g = g ii = f g li 

= / (1 + g) + ( g + l)li 
= f + h 

The following distributivity properties hold for the special case of compatible exten- 
sions. 

Property P4 

(/ o c) + ( i’ O c) = (/ + It) oC 

Property P5 

(c- O /) + (C 0 ll)Z C o(f + ll) 

Property P4 follows from the definition of + on function spaces. Property P5 follows 
from the monotonicity of c (all computable functions are monotonic), and becomes an 
equality for additive (see [25] p. 105) functions c. The special case of additive func- 
tions has some practical interest: functions computed by conflict-free subprograms on 
primitive data domains are additive. The resu'iction to primitive domains (which also 
appears in theorem 2) holds for subsets of programming languages that do not allow 
subprograms to be passed as parameters, do not support partially defined data struc- 
tures, and pass all parameters by value or by reference (i.e. no higher order functions, 
lazy evaluation, or call by name). 

We can get half of a distributivity law for compatible extensions from properties 
P4 and P5. 

Theorem 3. If g^Z fy h-, and “ /i, /j, then 

i/iofOlSio gi]{liio /M)C (/:[^;J /i:)o(/i[i',] /ll). 

Proof: 
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Suppose " /:, /ij and ^ /i, /ij. 

Then §:(^i(j:)) '~ <?;(/i(j:))C /:(/i(x)) for all x, so gt Z f z o f i- 
Similarly ^2 o = ho h- 



fi o /il<?2 o 5il hz o /ii = (/: o /i) + ( /12 o h) 

t (f 2 o / 1) (/: « ^*1) ( h o / 1) ■*■ ( '*2 o /*i) 

C fzo(fi + h 0 + hzo(fi+ h) 

= (/: + h) oif I + hi) 

= (/:[ 5:1 />:)o(/,[i?,]/J,) 



Lemma 3 

Property P5 
Property P4 
Lemma 3 



Theorem 3 can serve as the basis for an approximate method for merging compatible 
extensions that impact different modules of a system that are connected by data flows. 
This covers a situation in which methods based on program slicing, such as [12], 
would always report a conflict. Since theorem 3 is an inclusion rather than an equa- 
tion, such a method may report some extraneous conflicts (see Example 2 and the fol- 
lowing discussion). 

Our results impact current software development practices in some environments. 
Common sense suggests that a change to a module can affect all of the other modules 
that can receive data from the modified module. However, in informal conversations, 
several practicing software engineers have described real projects where different peo- 
ple were routinely assigned to make concurrent changes to modules with apparently 
unrelated functions, and the results of such updates were combined simply by linking 
the new versions of both modules into the system after both updates appear to have 
been implemented correctly. This practice appears to be based on belief in the 
(incorrect) distributivity property marked with a (?) at the beginning of this section, or 
on the unquestioned assumption that if both engineers did their job correctly, then all 
should be well. The results of this section show that this assumption is not always 
sound, and that the situation is far from simple in the general case. 

Example 1 shows that the results of combining changes to several different 
modules that are correct for each module in isolation can produce incorrect results 
when the modules are assembled into a system in such a way that the output of one 
changed module can reach the input of another changed module. More surprisingly, 
two changes to the same module that are consistent and produce correct results when 
the module is considered in isolation can produce an incorrect system-level result when 
the module is embedded in a larger system where nothing else has been changed 
(example 3), although the conditions under which this can occur are rather exotic. 

Some special cases where independent changes can be combined in isolation and 
then can be safely embedded in a larger system are identified in theorems 2 and 3. In 
other cases, when changes are combined, all modules whose inputs can be affected by 
the outputs of the changed modules must be checked together to establish the mutual 
correctness of the combined changes. The correcmess of the combined changes must 
be checked explicidy, in addition to checking the correctness of each change in isola- 
tion, since in the general case the combination can be incorrect even if each individual 
change produces correct results when considered in isolation form the other changes. 
The required check requires interprocedural analysis that can span large subsets of the 
system even if only a few modules of the system have actually been changed. Such 



checking can be quite expensive if it is to be done manually. This consideration pro- 
vides some support for test strategies that use program slicing to determine the impact 
of a change and to guide the selection of test data. 

It is natural to ask why this problem has not been noticed before, if it really is 
potentially serious. One relevant point is that the desired distributivity property is 
almost true, in the sense that it was fairly difficult to find counterexamples. We suc- 
ceeded in doing so only by explicitly analyzing the merging formula and several failed 
attempts to prove that the property was true. Thus failures due to this mechanism 
might not be easy to detect using small sets of test cases. Another point is that large 
systems in practice are subject to failures that do not have clearly understood causes: 
"integration problems" during system-level testing are common, as is "software rot" 
that gradually appears as systems go through a long series of changes. Although these 
problems are undoubtably due in part to human error, the counterexamples to the dis- 
tributivity law suggest that there may be other factors involved as well. At the current 
state of the an it would take a tedious experimental effon to accurately gauge how 
important these effects are in actual practice. This should become easier after reliable 
tools for semantically-based change merging are developed that can adequately treat at 
least one programming language that is used in large software development and 
maintenance activities. 

It is also natural to ask what practitioners can do to avoid merging problems 
before reliable change merging tools become available. Our results indicate that in the 
general case changes cannot be combined reliably without including the context of the 
change. If accurate behavioral specifications for submodules are available, then these 
can be used to break some of the dependency chains, thus reducing the size of the pan 
of the context that must be considered when implementing and checking a change 
[15]. This enables a higher degree of concurrency between the work of designers 
working on different changes without giving up serializability of the updates. In such 
an approach each change must be checked with respect to only one context (the one 
defined by the serialization order, and identified as the primary input of the top level 
step in [15]) because each change becomes part of the context for the next change in 
the serialization order. 

5. Conclusions and Future Work 

We have provided a characterization of the semantic properties of an operation 
for combining changes to software objects, and have shown that the formal model has 
some of the properties that we would intuitively expect. This characterization is 
independent of the programming language in which the software objects are described, 
and can be applied in many contexts. We note that the HPR algorithm [12] is correct 
with respect to our characterization for the cases in which it does not report any 
conflicts. One advantage of our formal model is that it provides a natural representa- 
tion for conflicts in the cases where the given changes cannot be consistently com- 
bined, The model can be applied to requirements and specifications in addition to pro- 
grams, if we accept the view that a specification is a predicate that characterizes the 
set of all acceptable system behaviors, although the details of this are not explored in 
the current paper. 
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In related work [6] we have applied our model of the change combination process 
to propose a new method for integrating changes to PSDL programs. PSDL is a 
language for prototyping large, real-time systems, which is based on an enhanced data 
flow model of computation [14]. This language includes features for expressing con- 
currency and real-time constraints. A formal semantics of PSDL can be found in [13]. 
An initial version of a method for combining changes to PSDL programs has been 
developed [6,8]. We are also investigating the application of this framework to the 
development of program transformations that change the semantics of a program in a 
disciplined way [4]. Such transformations are important in software evolution, and 
form a complement to the meaning-preserving transformations that are used in imple- 
menting executable specification languages and in program optimization. 

The results presented in this paper establish a clear correcmess criterion for 
software change merging. Much more work remains to be done before automated 
change merging can be realized in practice. In particular, the fact that the program 
merging operation does not distribute over functional composition (see Section 4.4) 
implies that changes to "independent" modules cannot in general be processed indepen- 
dently. This may provide some objective support for the common belief that software 
maintenance is difficult to do, and suggests that significant computational capacity may 
be required to reliably combine changes to large software systems. Section 4.4 deter- 
mines some of the conditions under which changes to subfunctions can be merged 
independendy. 

Since the exact solution to the program merging problem is undecidable, future 
work should explore the tradeoff between computational efficiency and the size of the 
subspace for which an algorithm can produce exact results. We would like to have 
reliable approximation algorithms that produce few spurious warnings and succeed in 
finding conflict-free merges in most of the cases where they exist. An initial step in 
this direction has been based on program dependency graphs [12]. A calculus for 
deriving change merges with fewer spurious conflicts and the capability to successfully 
merge speedup transformations with other changes is described in [2]. More work is 
needed to develop representations of programs that can support accurate program 
merge algorithms with wide coverage. The crux of the problem is to recognize 
equivalent program fragments that are not identical. Normal forms and transformation 
technology [9] are likely to be important for this aspect of the problem. 
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